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DOCUMENT-IDENTIFIER: US 20030120628 A1 



TITLE: Decentralized manv-to-manv relationship management in 

an object persistence management system 



KWIC 



Abstract Paragraph - ABTX (1 ): 

A manv-to-manv relationship management system. In an object persistence 
management system, a manv-to-manv relationship manager can include one or 

more 

related objects; a junction table storing relationships between the related 
objects; and, one or more corresponding links. Each link can correspond to one 
of the objects. Furthermore, each link can persist state information for the 
corresponding object in an associated object table. Finally, each link can 
manage the junction table responsive to changing relationships with others 
of 

the related objects. Importantly, as the present invention distributes the 
management of the junction table, a counter-operation management protocol 

can 

be provided which can resolve conflicts which arise in the management of the 
junction table in response to changing relationships among their associated 
objects. 



Current US Classification, US Primary Class/Subclass - CCPR (1): 
707/1 



Title -TTL(1): 

Decentralized manv-to-manv relationship management in an object 
persistence 
management system 



Summary of Invention Paragraph - BSTX (3): 

[0002] The present invention relates to the field of object state 
persistence and more particularly to manv-to-manv relationship management in 
an 

object persistence management system. 



Summary of Invention Paragraph - BSTX (5): 

[0004] As object-oriented technology has matured, it has proven to be an 
excellent solution for modeling problems, building prototypes, and rapidly 
deploying applications. Though object models for applications are often reused 
in other applications, one of the costlier tasks of development has been that 
of translating between object-oriented and non-object-oriented representations 
of application models. Consequently, the task of mapping objects both to non 
object oriented relational database tables and other non object oriented data 
sources has been the missing piece in object persistence management. 



Summary of Invention Paragraph - BSTX (8): 

[0007] In that regard, present object persistence management systems provide 
for one-to-one, one-to-many and manv-to-manv relationship management. In 
the 

case of one-to-one and one-to-many relationship management, present object 
persistence management systems provide decentralized, loosely coupled 

agents, 

referred to herein as "links", to manage each side of the relationship. In 
particular, each link manages the state of an object in the relationship and 
coordinates with a corresponding "counter-link" when necessary, as is 
well-known in the art. 



Summary of Invention Paragraph - BSTX (1 1 ): 

[0010] In this example, the values for the class reference to a unique 
instructor ID can dynamically change according to the state of the associated 
class and instructor objects at the time those objects are stored in the 
database. If the relationship management system correctly maintains the 
state 

of the reiated obiects as their relationships change, then the relationships 

can be correctly stored to the underlying database when the objects are saved 
to a data store. If the saved objects are later restored from the data store, 
then the relationships also can be conrectly restored. 



Summary of Invention Paragraph - BSTX (12): 

[001 1] Unlike one-to-one and one-to-many relationships, storing the state of 
many-tomany relationships is not as straightforward. This is so because a 
third, auxiliary table, referred to hereinafter as a "junction table", 
typically is required to store the relationship information. For example, if 
multiple students are enrolled in multiple classes in an 



instructor-class-student model, a manv-to-manv relationship will have been 
created as between the students and their respective classes in which they are 
enrolled. 



Summary of Invention Paragraph - BSTX (14): 

[0013] Since the management of manv-to-manv relationships requires the 
management of a third, auxiliary entity apart from the related entities, the 
links managing the relationship between the related objects must be concerned 
not only with the state of the related objects, but also with the state of the 
third, auxiliary entity. One common approach to solving the problem of 
managing the junction table includes introducing a relationship manager 
responsible for updating key-pair entries in the junction table. As links to 
either side of the relationship detect relationship changes, the links inform 
the relationship manager of the change . In consequence, the relationship 
manager can ensure that the iunction table has been updated accordingly. 



Summary of Invention Paragraph - BSTX (15): 

[0014] Significantly, the common solution to managing manv-to-manv 
relationships in an object model can require the addition of substantial 
infrastructure to the run-time portion of the object persistence management 
system. This is so because typical object persistence management systems are 
designed such that only application entities such as the links provide state 
data to be flushed to the database. Conversely, only application entitles can 
be retrieved from the database. The relationship manager, however, is not an 
application entity. Rather, the relationship manager merely is an artifact 
required to record the relationship state for manv-to-manv associations. 



Summary of Invention Paragraph - BSTX (16): 

[0015] The decentralization of the management of the junction table, 
heretofore, has been complicated by potential conflicts which can arise when 
persisting state changes in related objects to their associated object tables. 
For instance, links typically can buffer state changes prior to their 
persistence in a table. When buffering the addition of a relationship, the 
link can buffer the operation, " add [key-pair entry]". Conversely, when 
buffering the removal of a relationship, the link can buffer the operation, 
" remove [key-pair entry]". 



Summary of Invention Paragraph - BSTX (17): 

[0016] In both cases, however, it is possible that a corresponding link 
which manages the other portion of the relationship also can buffer the 



management operations pertaining to the key-pair entry. Specifically, it is 
possible that one link which manages the state of objecti buffers the 
operation, " add [objecti , object2]", while the link which manages the state of 
object 2 buffers the operation, "remove[object1 , object2]. When persisting the 
state of objecti and object 2, however, the timing of performing each buffered 
operation can undermine the integrity of the junction table. 



Summary of Invention Paragraph - BSTX (18): 

[0017] Specifically, where the buffered operations of the link which manages 
object 2 are performed prior to the buffered operations of the link which 
manages objecti , a conflict can arise. In consequence, despite the apparent 
disadvantages of the centralized management of the junction table, the 
relationship manager can be required to avoid such conflicts. Thus, there 
exists a need for a manv-to-manv relationship management system in which 
timing 

conflicts can be managed notwithstanding the absence of a centralized 
relationship manager. 



Summary of Invention Paragraph - BSTX (20): 

[0018] The present invention is a manv-to-manv relationship management 
system which overcomes the deficiencies of the prior art manv-to-manv 
relationship management systems which depend upon an auxiliary relationship 
manager. In the object persistence management system of the present 
invention, 

a manv-to-manv relationship manager can include one or more related objects; 
a 

junction table storing relationships between the related objects; and, one or 
more corresponding links. 



Summary of Invention Paragraph - BSTX (21): 

[0019] Each link can correspond to one of the objects. Furthermore, each 
link can persist state information for the corresponding object in an 
associated object table. Finally, each link can manage the junction table 
responsive to changing relationships with others of the related objects. 
Importantly, as the present invention distributes the management of the 
junction table, a counter-operation management protocol can be provided which 
can resolve conflicts which arise in the management of the junction table in 
response to changing relationships among their associated objects. 



Summary of Invention Paragraph - BSTX (22): 



[0020] The counter-operation management protocol can remove conflicted 
state 

information in the corresponding links without persisting the conflicted state 
information in the junction table. In particular, each of the corresponding 
links can include a state management operations buffer, the buffer storing 
directives for adding selected key-pair entries to and removing selected 
key-pair entries from the junction table. The counter-operation management 
protocol can include an interface through which operations in the buffer and 
corresponding counter-operations in associated buffers of related links can be 
identified and removed . Specifically, each counter-operation can specify a 
junction table management operation for a particular key-pair entry in the 
associated buffer which is opposite to an operation in the buffer which 
specifies a junction table management operation also for the particular 
key-pair entry. 



Summary of Invention Paragraph - BSTX (23): 

[0021] In one aspect of the invention, a method of managing a manv-to^manv 
relationship in an object persistence management svstem can include 
detecting a 

relationship change with a related object. Upon detecting a relationship 
change, a directive can be stored in a buffer, the directive specifying a 
management operation for changing the relationship in a junction table. 
Notably, the stored directive can be performed only if an opposite directive 
has not been stored in a buffer associated with the related object. 



Summary of Invention Paragraph - BSTX (24): 

[0022] Notably, the storing step can include storing a directive in the 
buffer which specifies one of adding or removing a key-pair entry in the 
junction table. In that regard, the performing step can include performing the 
specified adding or removing of the key-pair entry only if a corresponding 
opposite directive specifying a respective removing or adding of the key-pair 
entry is not detected in the buffer of the associated object. In that regard, 
if a corresponding opposite directive is detected, both the directive and 
opposite directive can be removed from both of the buffers. 

Brief Description of Drawings Paragraph - DRTX (3): 

[0024] FIG. 1 is a schematic illustration of a decentralized manv-to-manv 
relationship management system; and. 



Brief Description of Drawings Paragraph - DRTX (4): 



[0025] FIG. 2 is a flow chart illustrating a process for managing state 
changes in the decentralized manv-to-manv relationship management 
system of 
FIG. 1. 



Detail Description Paragraph - DETX (2): 

[0026] The present invention is a decentralized manv-to-manv relationship 
management system. In the manv-to-manv relationship management system of 
the 

present invention, links which traditionally manage the objects in a one-to-one 
and one-to-many relationship, also can manage the related objects in a 
manv-to-manv relationship. Specifically, the links can collaborate with one 
another bv providing updates to the junction table without the assistance 
of a 

non-application, auxiliarv relationship manager. Notably, unlike conventional 
manv-to-manv relationship management systems in which a centralized 
relationship manager manages the junction table, in the present invention, the 
responsibility for maintaining the Junction table can be distributed amongst 
the links. 



Detail Description Paragraph - DETX (3): 

[0027] Each of the links In the manv-to-manv relationship management 
system 

of the present invention can have an association with an object as the 
persistence manager for that object and, as such, can be considered an 
application entity. In consequence, the persistent state information managed 
by each link can be stored to and retrieved from data storage using the 
conventional flush and hydration mechanisms of preexisting conventional object 
persistence management systems. Thus, by eliminating the need for a 
centralized relationship manager, the complexity of managing manv-to-manv 
relationships can be dramatically reduced. 



Detail Description Paragraph - DETX (4): 

[0028] Finally, inasmuch as a conflict of flush and hydration operations can 
arise on opposite sides of a manv-to-manv association, a counter-operation 
process can be provided in accordance with the present invention. The 
counter-operation process can be performed in each of the links in the 
manv-to-manv relationship prior to the persistence of object states managed by 
each side of the manv-to-manv association. Specifically, prior to performing 
individual flush and hydration operations wherein the state of the managed 
objects are written to or deleted from their associated object tables, each 



managing link can inspect its own operational buffer and the operational buffer 
of the another to locate operations in both which run counter to one another. 
Where identified, these operations can be removed from the buffer without 
performing the corresponding individual flush or hydration operation. In this 
way, potential conflicts within the many-to-manv relationship can be avoided. 



Detail Description Paragraph - DETX (5): 

[0029] FIG. 1 is a schematic illustration of the decentralized manv-to-manv 
relationship management system of the present invention. As illustrated in 
FIG. 1 , the system can include two or more objects 108, 110 having a 
manv-to-manv object relationship. An example of two such objects can include 
the object relationship between classes in which students can enroll, and 
students who can enroll in classes. Other examples can include the object 
relationship between projects to which employees can be assigned, and 
employees 

who can work on projects. 



Detail Description Paragraph - DETX (6): 

[0030] In accordance with the inventive arrangements, an object persistence 
management system 100 can be included which can ensure the persistence of 
the 

object state in each object 108, 1 10 managed by the system 100. More 
particularly, links 104, 106 can be provided which can ensure the integrity of 
the state of the related objects 108, 1 10 in the manv-to-manv relationship. 
The links 104. 106 can be application entities which coordinate state 
changes 

among the related objects 108, 1 10 and whose coordinated states can be 
flushed 

to a data store and hydrated from a data store, for instance tables 1 12, 1 14. 



Detail Description Paragraph - DETX (7): 

[0031] The manv-to-manv relationships can be recorded in a junction table 
102. Specifically, the junction table 102 can store the state of the 
manv-to-manv relationship between the objects 108, 1 10 as is the case in a 
conventional junction table. Importantly, however, a centralized relationship 
manager does not manage the addition and deletion of data to and from the 
junction table 102, respectively. Rather, in the present invention each link 
104, 106 of the manv-to-manv relationship management system can manage 
the 

auxiliary table 102, thus eliminating the requirement that an artifact, 
non-application entity manage the auxiliary table 102. Specifically, the links 



104, 106 can manage the auxiliary table 102 according to an agreed-upon 
management protocol. 



Detail Description Paragraph - DETX (8): 

[0032] FIG. 2 is a flow chart illustrating the management of state changes 
in a primary link the decentralized manv-to-manv relationship management 
system 

of FIG. 1 . Importantly, by "primary link", it is meant that the object managed 
by the primary link enjoys a manv-to-manv relationship with other objects 
managed by corresponding secondary links. Of course, as one skilled in the art 
will recognize, each secondary link, from the perspective of their managed 
objects, in of themselves can be primary links. Hence, the term primary link 
is refenred to herein only as a matter of semantic convenience and not as a 
matter of operational distinction between the objects in a manv-to-manv 
relationship. 



Detail Description Paragraph - DETX (9): 

[0033] Beginning in block 202, the primary link can detect a request to 
change the state of its associated object bv altering the object's 
relationship 

with another related object. For instance, the request can be a request to add 
a new relationship as in the case of enrolling a student In a new class 
(Class.Add(Student) or Student.Add(Class)), or removing an employee from an 
existing project (Project. Remove(Employee) or Employee.Remove(Project)). In 
any case, in decision block 204, it can be determined whether the request is 
one to add or delete a relationship. 



Detail Description Paragraph - DETX (10): 

[0034] If the request is a request to add a new relationship, in block 206 
the primary link can change its internal state to reflect the new relationship 
with the related object. 



Detail Description Paragraph - DETX (11): 

[0035] Specifically, the link can buffer the operation, " add [new key-pair 
entry]" to reflect the new relationship. By comparison, if in decision block 
204 the request to change the object state is determined to be a request to 
delete a relationship between two objects, in block 208 the primary link can 
change its internal state to remove the relationship with the related object 
managed by the secondary link. In particular, as before the primary link can 
buffer the operation, " remove [existing key-pair entry]". 



Detail Description Paragraph - DETX (12): 

[0036] In decision block 210, if the state of object managed by the primary 
link is not to be persisted, the process can continue In block 202 wherein 
additional object state changes can be processed in the primary link . If, 
however, in decision block 210, the state of the object managed by the primary 
link is to be persisted, in block 212, the buffers of each secondary link 
associated with the primary link in a manv-to-manv relationship can be 
inspected for counter-operations to those operations stored in the buffer of 
the primary link. 



Detail Description Paragraph - DETX (13): 

[0037] Where counter-operations in a secondary link are identified, both the 
primary link and secondary link can remove the operation and corresponding 
counter-operation from their respective buffers in step 214. Finally, in step 
216, those remaining operations in the buffer of the primary link can be 
persisted to the junction table. Notably, though the counter-operation process 
of FIG. 2 is shown to occur subsequent to a decision to persist the state of 
the link, in a preferred embodiment, the counter-operation process illustrated 
in steps 212 through 216 can be performed in response to a decision to add or 
remove an operation to the link buffer. 



Claims Text - CLTX (2): 

1 . In an object persistence management system, a manv-to-manv 
relationship 

manager comprising: a plurality of related objects; a junction table storing 
relationships between said related objects; and, a plurality of corresponding 
links, each said link corresponding to one of said objects, each said link 
persisting state information for said corresponding object in an associated 
object table, and managing said junction table responsive to changing 
relationships with others of said related objects. 



Claims Text - CLTX (3): 

2. The manv-to-manv relationship manager of claim 1 , further comprising a 
counter-operation management protocol performed in said corresponding links 
for 

removing conflicted state Infomiatlon in said con-esponding links without 
persisting said conflicted state information in said junction table. 



DOCUMENT-IDENTIFIER: US 20030120628 A1 



TITLE: Decentralized many-to-many relationship management in 

an object persistence management system 



KWIC 



Abstract Paragraph - ABTX (1): 

A many-to-many relationship management system. In an object persistence 
management system, a many-to-many relationship manager can include one or 
more 

related objects; a junction table storing relationships between the related 
objects; and, one or more corresponding links . Each link can correspond to 
one 

of the objects. Furthermore, each link can persist state information for the 
corresponding object in an associated object table. Finally, each link can 
manage the junction table responsive to changing relationships with others of 
the related objects. Importantly, as the present invention distributes the 
management of the junction table, a counter-operation management protocol 
can 

be provided which can resolve conflicts which arise in the management of the 
junction table in response to changing relationships among their associated 
objects. 



Current US Classification. US Primary Class/Subclass - CCPR (1): 
707/1 



Summary of Invention Paragraph - BSTX (8): 

[0007] In that regard, present object persistence management systems provide 
for one-to-one, one-to-many and many-to-many relationship management. In 
the 

case of one-to-one and one-to-many relationship management, present object 
persistence management systems provide decentralized, loosely coupled 
agents, 

referred to herein as " links ", to manage each side of the relationship. In 
particular, each link manages the state of an object in the relationship and 
coordinates with a corresponding "counte r-link " when necessary, as is 
well-known in the art. 



Summary of Invention Paragraph - BSTX (9): 

[0008] Part of the relationship management process can include the 
management of the persistent state of the relationship. The management of the 
persistent state of the relationship can be relatively straightforward in the 
case of one-to-one and one-to-many relationships since the state of the 
relationship can be included as part of the state of the related objects 
themselves. Hence, If the links have con'ectly managed the related objects, 
when the objects are stored to an underlying database, the state of the 
relationship also will be stored. 



Summary of Invention Paragraph - BSTX (12): 

[0011] Unlike one-to-one and one-to-many relationships, storing the state of 
many-tomany relationships is not as straightfonward. This is so because a 
third, auxiliary table, referred to hereinafter as a "junction table", 
typically is required to store the relationship information. For example, if 
multiple students are enrolled in multiple classes in an 
instructor-class-student model, a many-to-many relationship will have been 
created as between the students and their respective classes in which they are 
enrolled. 



Summary of Invention Paragraph - BSTX (13): 

[0012] In consequence, a junction table unrelated to any particular object 
will be required in order to track those students enrolled in the multiplicity 
of classes at any one time. Specifically, each record in the junction table 
can include two fields linking the unique ID of a student with the unique ID of 
a class in which the student is enrolled. These records typically are referred 
to as "key-pair entries". Of course, the junction table can include multiple 
key-pair entries for each student, each key-pair entry reflecting only one of 
the several classes in which the student may be enrolled. 



Summary of Invention Paragraph - BSTX (14): 

[0013] Since the management of many-to-many relationships requires the 
management of a third, auxiliary entity apart from the related entities, the 
links managing the relationship between the related objects must be concerned 
not only with the state of the related objects, but also with the state of the 
third, auxiliary entity. One common approach to solving the problem of 
managing the junction table includes introducing a relationship manager 
responsible for updating key-pair entries in the junction table. As links to 
either side of the relationship detect relationship changes, the links infomn 



the relationship manager of the change. In cx)nsequence, the relationship 
manager can ensure that the junction table has been updated accordingly. 



Summary of Invention Paragraph - BSTX (15): 

[0014] Significantly, the common solution to managing many-to-many 
relationships in an object model can require the addition of substantial 
infrastructure to the run-time portion of the object persistence management 
system. This is so because typical object persistence management systems are 
designed such that only application entities such as the links provide state 
data to be flushed to the database. Conversely, only application entitles can 
be retrieved from the database. The relationship manager, however, is not an 
application entity. Rather, the relationship manager merely is an artifact 
required to record the relationship state for many-to-many associations. 



Summary of Invention Paragraph - BSTX (16): 

[0015] The decentralization of the management of the junction table, 
heretofore, has been complicated by potential conflicts which can arise when 
persisting state changes in related objects to their associated object tables. 
For instance, links typically can buffer state changes prior to their 
persistence in a table. When buffering the addition of a relationship, the 
link can buffer the operation, "add [key-pair entry]". Conversely, when 
buffering the removal of a relationship, the link can buffer the operation, 
"remove [key-pair entry]". 



Summary of Invention Paragraph - BSTX (17): 

[0016] In both cases, however, it is possible that a corresponding link 
which manages the other portion of the relationship also can buffer the 
management operations pertaining to the key-pair entry. Specifically, it is 
possible that one Mnk which manages the state of objecti buffers the 
operation, "add [objecti , object2]", while the Hnk which manages the state of 
object 2 buffers the operation, "remove[object1 , object2]. When persisting the 
state of objecti and object 2, however, the timing of performing each buffered 
operation can undermine the integrity of the junction table. 



Summary of Invention Paragraph - BSTX (18): 

[001 7] Specifically, where the buffered operations of the Miik which manages 
object 2 are performed prior to the buffered operations of the link which 
manages objecti , a conflict can arise. In consequence, despite the apparent 
disadvantages of the centralized management of the junction table, the 
relationship manager can be required to avoid such conflicts. Thus, there 



exists a need for a many-to-many relationship management system in which 
timing 

conflicts can be managed notwithstanding the absence of a centralized 
relationship manager. 



Summary of Invention Paragraph - BSTX (20): 

[0018] The present invention is a many-to-many relationship management 
system which overcomes the deficiencies of the prior art many-to-many 
relationship management systems which depend upon an auxiliary relationship 
manager. In the object persistence management system of the present 
invention, 

a many-to-many relationship manager can include one or more related objects; a 
junction table storing relationships between the related objects; and, one or 
more con^esponding links . 



Summary of Invention Paragraph - BSTX (21): 

[0019] Each link can correspond to one of the objects. Furthermore, each 
link can persist state information for the corresponding object in an 
associated object table. Finally, each link can manage the junction table 
responsive to changing relationships with others of the related objects. 
Importantly, as the present invention distributes the management of the 
junction table, a counter-operation management protocol can be provided which 
can resolve conflicts which arise in the management of the junction table in 
response to changing relationships among their associated objects. 



Summary of Invention Paragraph - BSTX (22): 

[0020] The counter-operation management protocol can remove conflicted 
state 

information in the corresponding links without persisting the conflicted state 
information in the junction table. In particular, each of the corresponding 
links can include a state management operations buffer, the buffer storing 
directives for adding selected key-pair entries to and removing selected 
key-pair entries from the junction table. The counter-operation management 
protocol can include an interface through which operations in the buffer and 
corresponding counter-operations in associated buffers of related links can be 
identified and removed. Specifically, each counter-operation can specify a 
junction table management operation for a particular key-pair entry in the 
associated buffer which is opposite to an operation in the buffer which 
specifies a junction table management operation also for the particular 
key-pair entry. 



Detail Description Paragraph - DETX (2): 

[0026] The present invention is a decentralized many-to-many relationship 
management system. In the many-to-many relationship management system of 
the 

present invention, links which traditionally manage the objects in a one-to-one 
and one-to-many relationship, also can manage the related objects in a 
many-to-many relationship. Specifically, the links can collaborate with one 
another by providing updates to the junction table without the assistance of a 
non-application, auxiliary relationship manager. Notably, unlike conventional 
many-to-many relationship management systems in which a centralized 
relationship manager manages the junction table, in the present invention, the 
responsibility for maintaining the junction table can be distributed amongst 
the links. 



Detail Description Paragraph - DETX (3): 

[0027] Each of the links in the many-to-many relationship management 
system 

of the present invention can have an association with an object as the 
persistence manager for that object and, as such, can be considered an 
application entity. In consequence, the persistent state information managed 
by each link can be stored to and retrieved from data storage using the 
conventional flush and hydration mechanisms of preexisting conventional object 
persistence management systems. Thus, by eliminating the need for a 
centralized relationship manager, the complexity of managing many-to-many 
relationships can be dramatically reduced. 



Detail Description Paragraph - DETX (4): 

[0028] Finally, inasmuch as a conflict of flush and hydration operations can 
arise on opposite sides of a many-to-many association, a counter-operation 
process can be provided in accordance with the present invention. The 
counter-operation process can be performed in each of the links in the 
many-to-many relationship prior to the persistence of object states managed by 
each side of the many-to-many association. Specifically, prior to performing 
individual flush and hydration operations wherein the state of the managed 
objects are written to or deleted from their associated object tables, each 
managing link can inspect its own operational buffer and the operational buffer 
of the another to locate operations in both which run counter to one another. 
Where identified, these operations can be removed from the buffer without 
performing the corresponding individual flush or hydration operation. In this 
way, potential conflicts within the many-to-many relationship can be avoided. 



Detail Description Paragraph - DETX (6): 

[0030] In accordance with the inventive arrangements, an object persistence 
management system 100 can be included which can ensure the persistence of 
the 

object state in each object 108, 1 10 managed by the system 100. More 
particularly, links 104, 106 can be provided which can ensure the integrity of 
the state of the related objects 108, 1 10 in the many-to-many relationship. 
The links 104, 106 can be application entities which coordinate state changes 
among the related objects 108, 1 10 and whose coordinated states can be 
flushed 

to a data store and hydrated from a data store, for instance tables 1 12, 1 14. 



Detail Description Paragraph - DETX (7): 

[0031] The many-to-many relationships can be recorded in a junction table 
102. Specifically, the junction table 102 can store the state of the 
many-to-many relationship between the objects 108, 110 as is the case in a 
conventional junction table. Importantly, however, a centralized relationship 
manager does not manage the addition and deletion of data to and from the 
junction table 102, respectively. Rather, in the present invention each link 
104, 106 of the many-to-many relationship management system can manage the 
auxiliary table 102, thus eliminating the requirement that an artifact, 
non-application entity manage the auxiliary table 102. Specifically, the links 
104, 106 can manage the auxiliary table 102 according to an agreed-upon 
management protocol. 



Detail Description Paragraph - DETX (8): 

[0032] FIG. 2 is a flow chart illustrating the management of state changes 
in a primary link the decentralized many-to-many relationship management 
system 

of FIG. 1 . Importantly, by "primary link ", it is meant that the object managed 
by the primary link enjoys a many-to-many relationship with other objects 
managed by corresponding secondary links . Of course, as one skilled in the art 
will recognize, each secondary link, from the perspective of their managed 
objects, in of themselves can be primary links . Hence, the term primary link 
is referred to herein only as a matter of semantic convenience and not as a 
matter of operational distinction between the objects in a many-to-many 
relationship. 



Detail Description Paragraph - DETX (9): 
[0033] Beginning in block 202, the primary Hnk can detect a request to 



change the state of its associated object by altering the object's relationship 
with another related object. For instance, the request can be a request to add 
a new relationship as in the case of enrolling a student in a new class 
(Class.Add(Student) or Student.Add(Class)), or removing an employee from an 
existing project (Project.Remove(Employee) or Employee. Remove(Project)). In 
any case, in decision block 204, it can be determined whether the request is 
one to add or delete a relationship. 



Detail Description Paragraph - DETX (10): 

[0034] If the request is a request to add a new relationship, in block 206 
the primary link can change its internal state to reflect the new relationship 
with the related object. 



Detail Description Paragraph - DETX (11): 

[0035] Specifically, the link can buffer the operation, "add [new key-pair 
entry]" to reflect the new relationship. By comparison, if in decision block 
204 the request to change the object state is determined to be a request to 
delete a relationship between two objects, in block 208 the primary link can 
change its internal state to remove the relationship with the related object 
managed by the secondary link . In particular, as before the primary link can 
buffer the operation, "remove [existing key-pair entry]". 



Detail Description Paragraph - DETX (12): 

[0036] In decision block 210, if the state of object managed by the primary 
link is not to be persisted, the process can continue in block 202 wherein 
additional object state changes can be processed in the primary link . If, 
however, in decision block 210, the state of the object managed by the primary 
link is to be persisted, in block 212, the buffers of each secondary link 
associated with the primary link in a many-to-many relationship can be 
inspected for counter-operations to those operations stored in the buffer of 
the primary link . 



Detail Description Paragraph - DETX (13): 

[0037] Where counter-operations in a secondary Imk are identified, both the 
primary link and secondary link can remove the operation and corresponding 
counter-operation from their respective buffers in step 214. Finally, in step 
216, those remaining operations in the buffer of the primary link can be 
persisted to the junction table. Notably, though the counter-operation process 
of FIG. 2 is shown to occur subsequent to a decision to persist the state of 
the link, in a preferred embodiment, the counter-operation process illustrated 



in steps 212 through 216 can be performed in response to a decision to add or 
remove an operation to the Mnk buffer. 



Claims Text - CLTX (2): 

1. In an object persistence management system, a many-to-many relationship 
manager comprising: a plurality of related objects; a junction table storing 
relationships between said related objects; and, a plurality of corresponding 
links, each said link corresponding to one of said objects, each said Mnk 
persisting state information for said corresponding object in an associated 
object table, and managing said junction table responsive to changing 
relationships with others of said /elated objects. 



Claims Text - CLTX (3): 

2. The many-to-many relationship manager of claim 1 , further comprising a 
counter-operation management protocol performed in said corresponding links 
for 

removing conflicted state information in said corresponding links without 
persisting said conflicted state information In said junction table. 



Claims Text - CLTX (4): 

3. The many-to-many relationship manager of claim 2, wherein each of said 
corresponding links comprises a state management operations buffer, said 
buffer 

storing directives for adding selected key-pair entries to and removing 
selected key-pair entries from said junction table. 



Claims Text - CLTX (5): 

4. The many-to-many relationship manager of claim 3, wherein said 
counter-operation management protocol comprises an interface through which 
operations in said buffer and corresponding counter-operations in associated 
buffers of related links can be identified and removed, each said 
counter-operation specifying a junction table management operation for a 
particular key-pair entry in said associated buffer which is opposite to an 
operation in said buffer which specifies a junction table management operation 
also for said particular key-pair entry. 



